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APOLLO EXPERIENCE REPORT 

DEVELOPMENT OF GUI DANCE TARGETING TECHNIQUES 

FOR THE COMMAND MODULE AND LAUNCH VEHICLE 

By Jerome D. Yencharls, Robert F. Wiley, Robert S. Davis, 
Quentin A, Holmes, and Kenneth T. Zeiler 
Manned Spacecraft Center 

SUMMARY 


To develop guidance targeting techniques for the Apollo command module and 
launch vehicle, it was necessary to consider the onboard- guidance capability; the mis- 
sion objectives, mission rules, and hardware constraints; the vehicle performance 
capabilities, trajectory characteristics, and crew time line; the current optimization 
and targeting techniques; the effect each maneuver would have upon subsequent maneu- 
vers; and the vulnerability of each maneuver to varying initial conditions. However, in 
accordance with the Apollo Program time line, these concepts and techniques were 
being developed in parallel with the development of targeting techniques. Consequently, 
the targeting development had to proceed in distinct phases, and each phase was de- 
pendent upon advances made in the previous phase. 

The development of the targeting procedures and associated real-time computer 
programs for four types of maneuvers is discussed. Each targeting program, with the 
exception of the Translunar- Injection Targeting-Update Program, has been used suc- 
cessfully to target maneuvers for each Apollo lunar mission. Although capable of ful- 
filling the program objectives, the Translunar-Injection Targeting-Update Program has 
not been needed during any Apollo lunar mission through 1969. 


INTRODUCTION 


Targeting Process 

A series of 22 joint meetings among NASA Manned Spacecraft Center (MSC) and 
prime contractor personnel was held in 1965 and 1966 to investigate the operational 
targeting procedures for the Apollo lunar missions. During these meetings, the basic 
concepts and framework were formed for the development of guidance targeting 
techniques. 
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The following definitions, which were derived during these meetings, are given 
to clarify the terminology used in this report. 

1. Targeting is the process followed to obtain guidance parameters for specific 
maneuvers throughout a mission. 

2. Target objectives are the exact requirements for a particular mission phase, 
which may be a single maneuver (e. g. , translunar injection (TLI)) or a series of ma- 
neuvers (e.g., translunar midcourse (TLMC) maneuvers). 

3. Target parameters approximate the target objectives within an acceptable 
degree of accuracy. 

4. Guidance parameters represent the target parameters in the guidance 
mechanization. 

As an example, this terminology is considered in context with the TLI targeting 
procedure. 

1. Target objective — A translunar trajectory that has a specified altitude and 
moon-referenced latitude at the closest approach to the moon 

2. Target parameters — Quantities that define the hypersurface, an analytic 
formulation that represents all possible translunar trajectories which satisfy the target 
objectives 

3. Guidance parameters — The elements and orientation of the desired elliptical 
trajectory at TLI cut-off 

The adequacy of a targeting procedure can be expressed in terms of a penalty 
function, that is, the penalty imposed on subsequent mission phases if the given target- 
ing procedure is followed and the given target parameters and guidance parameters are 
used. For TLI, this penalty function could be the midcourse velocity change AV re- 
quired to return the trajectory to the given target objectives for TLI. 


Development of Targeting Techniques for the Apollo Missions 

The development of the targeting procedures is discussed for four types of maneu- 
vers performed during the Apollo lunar missions: (1) TLI, (2) TLMC maneuvers, 

(3) lunar-orbit insertion (LOI), and (4) return to earth (RTE), which includes not only 
aborts from the nominal mission but also the nominal transearth injection (TEI) maneu- 
ver and the transearth midcourse (TEMC) maneuvers. The development of targeting 
procedures for the TLMC, LOI, and RTE maneuvers was the responsibility of MSC 
personnel. Because of the nature of the Apollo Program, the TLI targeting procedure 
was developed jointly by MSC and NASA Marshall Space Flight Center (MSFC) person- 
nel. Development of the target parameters and of the associated guidance equations 
was accomplished at MSFC. The real-time TLI targeting procedure and computer pro- 
grams for the TLI targeting update were developed at MSC. Of these TLI developments, 
the real-time procedure and targeting- update computer programs are discussed in this 
report. 
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For each of the four maneuvers considered, a computer program was developed 
for use in real time to determine the guidance parameters for the maneuver. The his- 
torical development of these programs and of the related targeting procedures is dis- 
cussed. To develop each program, it was necessary to consider the onboard- guidance 
capability, the mission objectives, the mission rules, the hardware constraints, the 
vehicle performance capabilities, the trajectory characteristics (principally geometry 
and energy), and the crew time line. Further development considerations were the 
current optimization and targeting techniques (state-of-the-art knowledge), the effect 
each maneuver would have on subsequent maneuvers, and the vulnerability of each ma- 
neuver to varying initial conditions. Because of the schedule imposed on the Apollo 
Program, the efforts in many of these areas were conducted simultaneously with the 
targeting development effort. Therefore, the progress of the targeting- technique de- 
velopment was directly related (1) to the developments occurring in other phases of the 
Apollo Program (e. g. , the definition of guidance capability, hardware development, 
etc. ), (2) to the development of analytical tools, and (3) to the definition of target objec- 
tives for each maneuver. 


TRANSLUNAR- INJECTION TARGETING UPDATE 


The TLI Targeting- Update Program was completed during the summer of 1968 
and was first put into a real-time system for the Apollo 12 mission. The circumstances 
that would lead to the decision to update the targeting of the launch vehicle for the TLI 
maneuver had remained in doubt up to that time. 

The development of the TLI Program was concurrent with the definition of guid- 
ance equations; the development of the mission profile; and the development of hard- 
ware, software, and the associated constraints. The TLI Program also depended 
heavily upon the Generalized Forward Iterator. Some inefficiencies occurred in TLI 
Program development; however, like many other developments in the Apollo Program, 
the TLI Program began with inexperienced personnel who faced a restrictive time line 
and the realization that this effort was also highly interdependent on other developments 
in the Apollo Program. 


Pre-1967 Development 

Interface between guidance equation development and targeting t echniques . - From 
the outset of the Apollo Program until 1965, the launch vehicle guidance and targeting 
functions were not well defined. However, within a few years after the Apollo Program 
began, some detailed preliminary logic and equations for the command module com- 
puter (CMC) had been developed at the Massachusetts Institute of Technology (MIT). 

Included among the programs available for the CMC was a set of guidance equa- 
tions for TLI backup; that is, this guidance was to be used if the launch vehicle could 
not perform the steering for the TLI burn. Cross-product steering, which was the type 
of guidance for the CMC, used as target parameters a desired semimajor axis a and 
three position components of a target vector r^. 
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When the CMC equations became available, a significant effort was directed 
toward understanding, analyzing, and evaluating the equations and developing ground- 
based logic to support the targeting problem. Two approaches were taken to develop 
the targeting logic. 

1. To iterate on the components of and on a to achieve an optimum TLI 

maneuver that would place the spacecraft on a free-return trajectory that had nominal 
perilune conditions 

2. To iterate on ignition time and to vary the outbound trajectory in an attempt 
to fit the problem to the guidance capability 

For the second approach, the TLI AV was not optimized within the cycle, but the over- 
all effect of varying the set of the parameters on injection AV and midcourse AV was 
considered. 

Studies were conducted for nominal and dispersed cases. A significant emphasis 
was placed on a study of dispersed cases. However, the dispersions used (for earth- 
orbit insertion) were for an open-loop Saturn IV (S-IV) guidance scheme and were 
greater than the dispersion characteristics of the closed-loop scheme used on the S-IVB 
for the lunar flights. The results of the study indicated a need for targeting update. 
However, in late 1965, dispersion characteristics became available for the S-IVB, and 
the study was performed again. This time, no targeting update was required in the 3o 
case. 


The main drawback of these initial studies was that only coplanar translunar in- 
jections were considered. Insufficient information was available about the targeting 
philosophy and the launch window design based on that philosophy. 

Launch -vehicle guidance for T LI. - In the summer of 1965, an effort was begun to 
investigate the TLI guidance and targeting routines on board the launch vehicle. The fol- 
lowing items were considered. 

1. What would be involved in the TLI targeting update? 

2. What were allowable 3 a deviations at earth -orbit insertion before the update 
had to be made ? 

3. Did any targeting -update capability exist in the launch vehicle; and, if so, what 
were the details? 

In late 1965, an initial set of guidance equations was obtained. Within several 
months, the equations were programed into a computer simulation at MSC, The target- 
ing routine for TLI (the hypersurface eventually developed at MSFC) was preliminary 
and was not completely understood by MSC personnel for some time. 
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Initial development of the prototype real-time program . - Meanwhile, a prototype 
real-time program was under development by contractor personnel who used the analy- 
sis and development at MSC of the in-house version of the program. The TLI update 
problem in this prototype program was treated as an extension of the translunar mid- 
course problem. Like the midcourse, TLI was investigated by using a mission design 
program, a version of the Generalized Forward Iterator. The complicated logic for 
TLI update had two options: (1) to design TLI and accomplish a full- mission optimiza- 

tion or (2) to design TLI to inject the spacecraft into a free- return trajectory that had 
nominal perilune conditions. The logic had to have the capability to consider a change 
of the designated lunar landing site in real time. Finite burns and the required analytic 
calibration for the finite burns were taken into account. By June 1966, the prototype 
program was composed of the following necessary modules. 

1. The integration package 

2. The TLI guidance equations (launch vehicle and CMC) 

3. The LOI guidance equations 

4. The translunar midcourse correction package 

5. The first-guess logic 

6. The forward iterator 

7. The TLI burn calibration 

8. The Jacobi calibration 

9. The LOI burn calibration 

10. The CSM lunar-orbit plane change (LOPC) burn calibration 

11. The TEI burn calibration 

The first-guess package was designed only to place the trajectory of the space- 
craft in moon reference and on the correct side of the moon. The launch vehicle TLI 
guidance equations, the Iterative Guidance Mode (IGM), had been programed, as had 
all the burn calibrations. However, the TLI burn calibration had the capability for 
nominal cases only, and the other calibrations were to be nullified when CMC cleanup 
began and the spacecraft guidance laws changed for several of the burns. 

Deletion of spacecraft TL I guidance . - Among the first changes that were made to 
the CMC guidance equations in "early 1966 was the deletion of the TLI (r T , a) steering. 

A guidance interface still existed between the spacecraft and the launch vehicle; and, by 
mid- 1966, an extensive effort was being conducted by MIT personnel to implement the 
TLI equations (IGM) into the CMC. Later in 1966, further deletions were made on CMC 
programs, and the IGM equations were among the first to be eliminated. 

In summary, by the end of 1966 no change had occurred in the TLI update problem 
in the real-time prototype program. Full-mission optimization in earth parking orbit 
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was being considered. Because of a complicated setup of the iterator, many logical 
paths had to be followed in the program. The problem was sensitive and was heavily 
dependent on a combination of good first guesses and proper setup of the iterator. 

Much of the work that had been completed was inapplicable to the problem. Time had 
been spent at MIT and at MSC in the development and evaluation of the TLI (r T , a) back- 
up guidance equations, which were now useless. An extensive effort had been put for- 
ward at MIT to enter the IGM equations into the CMC, and digital and analog studies 
were well underway when the decision was made to take the IGM out of the CMC. 


Program Development During Late 1966 and 1967 

In 1966 and 1967, extensive development of the TLI targeting technique and of the 
real-time computer complex (RTCC) TLI Targeting- Update Program was accomplished. 
In late 1966, when no CMC program was available to back up TLI (although Lambert's 
targeting in conjunction with cross-product steering was being evaluated for this pur- 
pose at the time), interest increased concerning the capability to update the TLI targets 
on board the launch vehicle. The initial RTCC requirements for the TLI planning proc- 
essor were to be due in the summer of 1967; therefore, it was necessary to determine 
as quickly as possible what capabilities it should contain. In April 1967, the onboard 
targeting -update capability was defined. Two targeting -update options were defined: 

(1) the hypersurface quantities were updated or (2) only the time of restart preparation 
and the desired cutoff ellipse were specified. During MSC-MSFC discussions, it was 
decided that the first capability was not required; therefore, the decision was made to 
support only the second targe ting -update option. 

Initial RTCC requirements . - In the summer of 1967, the first RTCC requirements 
were submitted to the contractor for the TLI planning processor. Although the signifi- 
cant decision not to allow a change of the desired lunar landing site in real time simpli- 
fied the program, it remained somewhat cumbersome. A decision also was made to 
put into the RTCC TLI Targeting- Update Program the capability to update the CMC with 
Lambert's targeting for TLI. 

In the initial definition of the TLI Targeting-Update Program, four options were 
available for real-time planning consideration. 

1. Solve onboard targeting (hyper surface). 

2. Optimize the full mission in earth parking orbit. 

3. Maximize apogee altitude for the amount of S-IVB AV available. 

4. Execute TLI to place the spacecraft in a trajectory with a specified apogee 
altitude. 

Option 1 was indicative of what would happen if no targeting update was made. 
Option 2 optimized the service module fuel reserves for the full mission. Option 3 was 
made available for a nonnominal situation in which the S-IVB did not have adequate AV 
to perform the nominal TLI maneuver. Energy was maximized (in terms of apogee 
altitude), and a transfer maneuver possibly could be made from that trajectory to con- 
tinue the nominal mission or to execute an alternate lunar mission. Option 4 was made 


6 


I I 


■ii mi in i! aiw i si i i il mi 


I ! I III!! 1 II! Ill I II 


available for alternate earth- orbit missions and, more specifically, for the nominal 
earth- orbit lunar-landing- simulation mission (E-type mission) that was planned at the 
time. 


All four options could be viewed for either a first or a second TLI opportunity. 
For each option, one pass to generate the spacecraft targeting for TLI (Lambert's tar- 
geting) was made through the IGM equations after the last iteration. As a measure of 
merit, a midcourse correction was computed for options 1 and 2; the midcourse was 
targeted back to the nominal nodal conditions. 

The first set of requirements was rather complex. The IGM guidance equations 
had to be added to the program. The full -mission- optimization logic was complex and 
required extensive supportive analysis that would include analysis of the calibration- 
burn models. In 1967, the onboard (CMC) guidance equations were being changed con- 
stantly, because the requirements for onboard computer space were somewhat greater 
than the space available; thus, constant updates of the calibration- burn models were 
required. The one calibration on which work progressed steadily and by which good 
results were produced was that for an S-IVB-guided TLI. The major part of the work 
connected with this calibration was completed in 1967. 

Significant simplification in RTCC requirements. - The results of a study con- 
ducted in late 1967 indicated that the full-mission optimization was not necessary to 
the TLI planning program. Thus, the second option in the program could be simplified. 
The study showed that nothing was saved by optimizing the mission while in earth orbit 
and that, by targeting to the nominal perilune altitude and latitude and for free return, 
no AV penalty would be incurred. A decision also was made to drop the TLI guidance 
program from the spacecraft computer. 

These developments resulted in updated requirements for the TLI planning pro- 
gram. Full- mission optimization was eliminated as option 2; the new procedure was 
to target TLI to the nominal perilune conditions (altitude and latitude) and for free re- 
turn. The procedure for generating spacecraft targets (Lambert's targeting) was re- 
moved from the program. 

In summary, the program was at a relatively sound level in the winter of 1967 
and 1968. Although the first set of programing requirements had been complicated, 
simplification of the second set had been made possible by the deletion of the full- 
mission optimization. The only inefficiency that occurred during this period resulted 
from changes to the guidance requirements in the CMC. However, at the end of this 
period, it appeared that onboard and ground-based logic was becoming stabilized. 


Development of Current Programs 

Further simplifications of the re al-time program * - At the beginning of 1968* even 
though the TLI update problem was relatively simple* further simplifications were 
made. The IGM guidance equations were removed from the program. The retention of 
these equations was no longer necessary because of the deletion of the spacecraft TLI 
program. 
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Option 2 continued to be the cause of most of the problems. The first- guess pack- 
age that had been developed for option 2 was empirical, and physical conditions could 
exist in which the first-guess logic would provide inaccurate first guesses to the iter- 
ator. The empirical simulation of the TLI burn used in all four options was hampered 
because the simulation was reliable only for the variations that had been considered for 
the parameters which it generated; the simulation did not have the capacity for very 
large plane changes that could occur in the iteration process. Eventually, workaround 
procedures were developed for all known possible sources of error; and, in the summer 
of 1968, a revised set of program requirements was sent to the contractor. 

Impact of the A pollo 8 mission on program development. - In the fall of 1968, ob- 
jectives for the Apollo 8 mission were announced. Because the RTCC would have to 
support a lunar mission within 4 months, it was decided to make the ground-based sys- 
tem in the RTCC as simple as possible and yet give it the capability to support the mis- 
sion satisfactorily. Accordingly, the TLI Targeting- Update Program was not added to 
the system. 

From the fall of 1968 to the* summer of 1969, the TLI Targeting- Update Program 
was dormant. The program was not a part of the RTCC system for the Apollo 8, 10, 
and 11 missions. During the winter of 1968, a decision was made to eliminate the TLI 
Targeting- Update Program. In the summer of 1969, this decision was reversed, and 
the program was put into the RTCC system for the Apollo 12 mission. 

Program on th e RTCC system for the Apollo 12 mission. - In mid- 1968, several 
discussions were held with MSFC personnel regarding the processor. Personnel at 
MSC assumed that MSFC personnel would verify the RTCC capability to update the 
launch vehicle and to perform a satisfactory TLI, based on the targeting update. Per- 
sonnel at MSFC requested that definite guidelines be established in regard to when this 
update capability would be used. In subsequent discussions between personnel of the 
two centers, a conflict existed about establishing these guidelines; therefore, the veri- 
fication effort was not begun. 

Meanwhile, an outline of the requirements had been made at MSC for the targeting - 
update capability. It was generally agreed among MSC personnel that retargeting was 
required to ensure efficiency and to provide the broadest capability. The circumstances 
that were considered by MSC to warrant consideration of a real-time targeting update 
were as follows. 

1. Provision for a real-time targeting-update capability in the presence of launch 
vehicle malfunctions or launch vehicle onboard-programing logic (or both) that would 
permit the achievement of earth orbit but with insufficient S-IVB propellant to achieve 
nominal TLI- guided cut-off 

2. Provision for a real-time targeting capability in the presence of launch ve- 
hicle malfunctions or launch vehicle onboard programing logic (or both) that would per- 
mit the achievement of an earth parking orbit which would fall outside the capability of 
onboard targeting to compute a correct target or any target at all 


8 



3. Provision for a rapid (1 to 2 days) pi'e launch targeting capability to accommo- 
date last-minute changes to the mission or to the launch dates and to accommodate 
launch windows in excess of 3 or 4 days 

4. Provision for the operational capability to accommodate real-time launch ve- 
hicle or spacecraft problems that could necessitate an injection attempt on the third 
opportunity 

5. Provision for general operational real-time capability to accommodate any 
unknown or undefined launch vehicle or spacecraft problem that would prohibit the use 
of the normally computed launch vehicle TLI target 

The program for the Apollo 12 mission had been changed little since the summer 
of 1968. A targeting -update command load was generated during the Systems Integra- 
tion Test and sent to the S-IVB. A verification was received that the command load 
was accepted and ignition would be commanded at the correct time. The processor was 
available in real time for the Apollo 12 mission but was never called up, because the 
predicted TLI maneuver seemed reasonable. 

Development of improved first-gues s logic . - Because of the high perilune alti- 
tudes achieved when the hybrid trajectory profile was used, the first-guess package in 
option 2 yielded poor first guesses. Although this package was improved somewhat for 
the Apollo 12 mission, it was decided to develop a new analytic first-guess package 
that would be relatively insensitive to the trajectory profile flown. A task was assigned 
to one of the contractors for the development of the logic under the supervision of MSC 
personnel. 

However, during the initial planning for the Apollo 13 mission, a decision was 
made to use a constant time of arrival at the moon as one of the target objectives for 
TLI. Because of this decision, the problems with the empirical first-guess package 
disappeared. If this philosophy is maintained for the remainder of the Apollo missions, 
it is probable that the empirical first-guess package will work well. 

In summary, because of the time and effort that would be involved to Incorporate 
the version from the contractor's task into the RTCC system, it was decided to keep the 
existing TLI program in the RTCC and not to implement the contractor -developed logic 
for either the Apollo 14 or the Apollo 15 mission. In fact, if the same philosophy of 
constant time of arrival is used for the remainder of the Apollo Spacecraft Program, 
the logic developed by the contractor personnel will probably not be needed for real- 
time use. 


TRANSLUNAR MIDCOURSE 


Early in the Apollo Program, lunar trajectories were found to be extremely sen- 
sitive to dispersions at TLI. Because of this sensitivity, it was improbable, from an 
operational viewpoint, that TLI would be performed accurately enough to achieve a tra- 
jectory which would permit a desirable LOI without the need to execute a TLMC maneu- 
ver. The RTQC mid course- correction processor was designed to determine flight 
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maneuvers during translunar coast. Although an estimate of the probable deviations 
(3o) in TLI was derived from statistical studies, the RTCC processor had to be capable 
of computing an acceptable trajectory and target parameters from any possible cut-off 
vector at TLI, 


initial Requirements 

It was realized that the TLMC maneuver would affect the time line of the entire 
mission and that complete optimization would entail recomputation of all major maneu- 
vers to determine the best adaptive path (BAP) modes. If a severe dispersion at TLI 
precluded a nominal lunar mission, the midcourse processor would be used to compute 
alternate mission plans with better fuel reserves and to compute precision free-return 
trajectories (flyby modes) for use if a lunar-orbit mission was no longer desirable. 

Optimization of the midcourse maneuver was of primary importance because 
spacecraft AV budgets were limited. Speed of computation was essential because the 
midcourse AV usually increased with delay time, and the evaluation of several alter- 
native maneuvers might be required. Patched conic trajectories were used because 
many trajectories had to be computed to determine an optimum. It was assumed that, 
with a judiciously chosen value for the sphere of influence of the moon, the end condi- 
tions that were optimum for patched conic trajectories also would be optimum for a 
precision trajectory. The BAP modes of the midcourse processor were to be exercised 
only during the period from 5 to 20 hours after TLI. 

Because of lead-time considerations, the existing mission-design program was 
used as the basic vehicle for the midcourse processor. However, the Generalized For- 
ward Iterator was a general program with far more capability than the midcourse phase 
required. A much more specialized and regimented program was required for the real- 
time environment, and for this reason, a formal midcourse philosophy was needed. 

The initial real-time midcourse program design philosophy was a product of the 
combined efforts of MSC and three contractors. The personnel in these groups specified 
and developed a set of mission profiles that the midcourse processor would compute. 
These profiles or options represented all the possible trajectory sequences that were 
considered feasible in mid-1967. 


Computational Options of the Midcourse Processor 

Detailed logic was developed for seven options in the midcourse processor during 
the initial program development. 

Option 1 — nodal targe ting. - For option 1 (X, Y, Z, and T targeting), a trajectory 
was computed from point A to point B. Option 1 was the simplest and, therefore, most 
foolproof of all options. At the midcourse position, the maneuver was computed to de- 
termine a trajectory that would bring the spacecraft to the nominal location (X, Y, Z) of 
LOI at the nominal time T. This option was applicable to any mission scheme, if a set 
of target parameters was known. The resulting trajectory was a free return only if the 
nodal targets were associated with a free-return trajectory, based upon the position of 
the spacecraft at maneuver time. 


10 


Option 2 — - fixed lunar parking orbit, _free return . - Because Apollo Program 
planning was committed to free-return trajectories, the midcourse processor had to 
have the capability for computing a free-return trajectory that would intercept the nom- 
inal lunar parking orbit. This specification resulted in option 2, the fixed-orbit, free- 
return BAP. While retaining the nominal lunar- orbit orientation, this option 
reoptimized a complete free-return mission profile that included LOI, an LOPC to 
enable the command and service module (CSM) to pass over the lunar landing site a 
second time, and TEI maneuvers. 

Option 3 — free lunar parking orbit, free return . - Concern over dwindling fuel 
reserves because of continued weight growth of the spacecraft resulted in the inclusion 
of option 3, the free-orbit, free-return BAP. Because of the launch-window- design 
philosophy, a single lunar-landing- site approach azimuth, usable over a 3- month period, 
was to be selected on the basis of positive fuel reserves. Therefore, on a specific 
launch day and with a TL1 dispersion, the nominal azimuth was not necessarily optimum. 
To provide for this contingency, option 3 was devised by retaining the free-return as- 
pect of option 2 but freeing the azimuth at the lunar landing site. Full optimization de- 
termined a new approach azimuth that resulted in slightly less propellant being used 
than in the solution computed by option 2. 

Options 4 and 5 — nonfree return. - Options 4 and 5 represented a logical exten- 
sion of the ideas that produced option 5". If TLI dispersions were great enough to make 
a free-return mission too costly in terms of av, a nonfree return (NFR) possibly 
would permit continuation of the mission. Relaxation of the free-return trajectories 
was not considered for the first lunar flights. However, the lunar module descent en- 
gine could be used, within limits, as a backup (descent propulsion system abort) to re- 
turn the spacecraft safely to earth. Because of this safety margin, limited NFR 
trajectories became an actual alternative in real time. 

Option 4 (fixed-orbit NFR BAP) was designed to provide the midcourse processor 
with any capability that might be required for the use of NFR trajectories while retain- 
ing the nominal approach azimuth to the lunar landing site. Because translunar flight 
time was not uniquely determined on an NFR trajectory, a polynomial 6 (AT) was de- 
veloped to predict the optimum translunar trip time during the first 20 hours of trans- 
lunar coast (based upon the position and energy of the spacecraft and the current 
earth- moon geometry). 

Option 5, the free-azimuth version of option 4, had so much latitude that it would 
not reliably optimize to completion. Moreover, if a zero AV LOPC maneuver was en- 
countered, a nonoptimum solution would often be returned. To overcome this difficulty, 
the user of option 5 was allowed to specify by input (manual -entry device) whether to 
allow a range of approach azimuths or to compute a discrete, nonnominal azimuth. By 
using a series of discrete azimuth solutions in conjunction with a midcourse Trade-Off 
(TO) Display, the dependence of end-of-mission fuel reserves upon the approach azi- 
muth could be determined. Option 5 was included in the program specifications but was 
recommended for use In real-time analysis rather than for mission support. 
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Optio ns 6 and 7 — lu nar flybys. - Options 6 and 7 {lunar flybys) completed the 
original sefoF mission profiles. The intent was to provide computational support for 
alternate missions in the event of a badly dispersed TLI. It was in this aspect that 
questions arose concerning the prevailing assumptions and specifications for optimiza- 
tion. Option 6 was supposed to be an optimized lunar flyby passing through the nominal 
perilune latitude and altitude, whereas option 7 was to retain the constraint on perilune 
latitude, and the user was to specify perilune altitude by manual input. The prevailing 
assumptions and constraints were not unreasonable for large midcourse maneuvers 
(a AV of approximately 1500 ft/sec) executed early in translunar coast. Targets that 
were determined by conic optimization yielded midcourse maneuvers on integrated tra- 
jectories that were nonoptimum by approximately 35 ft/sec; for extensive midcourse 
maneuvers, this error could be considered acceptable. However, for small midcourse, 
maneuvers such as those that occurred during the Apollo 8 mission, the differences be- 
tween conic and integrated trajectories caused the small dispersion to be overwhelmed 
and thus invalidated this entire approach. In mid- 1967, it was known that, if disper- 
sions occurred, a perilune altitude other than nominal could result in a less expensive 
lunar flyby. Therefore, option 7 was created in the hope that repeated use of the option 
might permit the user to determine empirically an optimum lunar flyby during real time. 


Adapting to the Real-Time Environment 

The complexity of the various mission profiles and the real-time requirement of 
speed and reliability were considered indications of the need for program automation. 
The idea of ” wiring the man out 11 to reduce human error was a significant factor in the 
construction of the program supervisor logic. Each option was to be executed as auto- 
matically as possible from stored data. However,, the forward iterator needed initial 
values, or first guesses, to begin solving problems. These values were critical and 
varied significantly with different launch days and even with different launch azimuths 
and TLI opportunities. The conflict of varying initial values and stored data was solved 
primarily by contractor personnel with the concept of the Data Table. 

The Data Table was designed to store the independent variables in such a way that 
the following conditions existed, 

1. The nominal values could be loaded preflight. 

2. The nominal values could be updated by midcourse computations. 

3. All values could be manually overridden. 

The Preflight Data Table was used in program testing. Because a table was re- 
quired for each possible time of launch, 10 distinct Data Tables existed for each launch 
day. Preflight Data Tables were generated for launch azimuths of 72° , 81°, 90°, 99°, 
and 108° for both first and second TLI opportunities. When a specific launch azimuth 
was selected, the appropriate Data Table was constructed by interpolation. This Data 
Table was called Data Table 1 . 


12 



The midcourse processor, therefore, started each mission with an interpolated 
table. When a BAP was computed, the processor would create an updated table from 
the associated values of the independent variables. The midcourse processor could 
store (in the midcourse TO Display) as many as six computed mission profiles. Each 
BAP that was displayed had the implicit capability to produce an updated table. Such a 
table could be created and displayed by requesting Data Table 2. This second table was 
experimental in that a certain amount of mission planning was allowed to continue with- 
out affecting the rest of the midcourse system. Any succeeding midcourse computation 
could use either the first or the second table for initial values. The second table, based 
upon precision propagation, was usually preferable, because the first table held only 
conic data. 

When a computed midcourse BAP maneuver was actually executed (or transferred 
to the Mission- Plan Table), the independent variables associated with the maneuver 
were loaded into Data Table 3. All succeeding midcourse computations used Data 
Table 3, unless otherwise specified. Independent variables associated with the next 
executed BAP maneuvers were loaded into the fourth and fifth tables. If still another 
maneuver was executed, the table from that BAP went into the fifth table. The old data 
in the fifth table went into the fourth table, and the fourth into the third; and the old 
data in the third table were deleted. By this procedure, the execution of any number of 
BAP maneuvers was allowed, and an adequate maneuver history was retained. 


Limitations of Conic Optimization 

Another difficult problem in the midcourse processor stemmed from the relation- 
ship between conic- and integrated- trajectory propagation. For computational speed, 
a conic -trajectory computer was used for all of the options during optimization. When 
optimization was complete, an integrated trajectory was computed that satisfied the 
same end conditions at the moon. The midcourse maneuvers obtained with the conic 
and precision trajectories were considerably different. To decrease the number of 
iterations required to converge precision trajectories, a polynomial S(AV) was devel- 
oped for application to the conic value for the scalar velocity at midcourse. Contractor 
personnel later suggested that computations begin with the desired end conditions at the 
moon and converge to the midcourse position with precision propagation to overcome 
this same difficulty. When this scheme was incorporated into the program, the results 
were even better; thus, the 6 (av) polynomial was discarded. 

Because the midcourse maneuver that was predicted during optimization was con- 
siderably different from the maneuver derived by using precision trajectories, the 
solutions were not fully optimized. Near the end of 1967, personnel of one of the con- 
tractors realized the inadequacy of the specifications for optimizing lunar flybys, but 
the problem could not be solved at that time because of insufficient understanding of 
flybys. 
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Apollo 8 Mission — Lunar Flybys and the 
Vector Offset Techniques 

Considerable effort and time were expended to improve the conic program by re- 
ducing the program error. Work was completed on lunar- sphere- size studies, Jacobi 
calibrations, and hybrid patched conic trajectories. When the Apollo 8 mission was 
scheduled as a CSM solo lunar mission, optimum lunar flybys were required to be com- 
puted from near- nominal trajectories at any time during translunar coast. This new 
requirement was met by the vector offset method that was developed at MSC chiring the 
activity which preceded the Apollo 8 mission. 

By use of the standard conic- and integrated-propagation routines, the supervisor 
logic was structured to measure the difference in midcourse maneuvers between com- 
parable conic and precision trajectories. This difference was applied as a velocity 
bias, or offset, to the premidcourse state during conic optimization. Thus, the inte- 
grated midcourse maneuver could be optimized while a conic trajectory computer was 
being used. 

Application of the vector offset to the flyby optimization opened up a new field of 
lunar trajectories as possible solutions to the problem. These trajectories led to a 
better understanding of the problem and resulted in a complete revision of the original 
flyby specifications. New flyby options, 8, 9a, and 9b, provided a variety of flyby 
capabilities. By use of option 9a, a flyby was possible that used the true minimum AV 
to return to earth within a range of inclinations of return and perilune altitudes. When 
option 9b was employed, the optimum lunar flyby for a specified inclination and range 
of perilune altitudes was achieved. By use of the computational support provided by 
option 9a, the free- return landing point could be moved from any place on earth into 
deep water, for an additional AV of less than 50 ft/sec. The use of option 8 resulted 
in a lunar flyby to a specified inclination of free- return and perilune altitude. Although 
option 8 did not involve optimization, the vector offset was used to compute accurate 
first guesses for the integrated maneuver. Because of a lack of lead time, the new flyby 
options were not incorporated into the Apollo 8 RTCC midcourse processor, but these 
options were made available in the Real-Time Auxiliary Computing Facility and were 
exercised throughout translunar coast during the Apollo 8 mission. All modes of the 
midcourse processor were required to function throughout translunar coast. 


Vector Offset Applied to NFR Options 

In early 1968, the NFR options, as specified, were found to be nonoptimum for 
small midcourse maneuvers because of the ubiquitous difference between patched conic 
and precision propagation. Application of a velocity bias at the midcourse point could 
not completely eliminate the problem, because, unlike the case of free-return trajec- 
tories, translunar flight time on an NFR trajectory was not uniquely determined by the 
nodal position. The application of a velocity offset at both ends of the translunar tra- 
jectory during conic optimization and the use of flight time to terminate each trajectory 
comprised the solution. A consequence of the solution was coupled optimization of both 
the midcourse and the LOI maneuvers into a close approximation of the actual maneu- 
vers. The principal values of NFR trajectories were recognized to be the fuel savings 
and translunar-trip-time flexibility when these trajectories were used in conjunction 
with the hybrid mission profile. 
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Apollo 10 and 11 Missions — Vector Offset incorporated 
into Free- Return BAP Options 

The decision to use the same lunar orbit orientation on the Apollo 10 flight as on 
the Apollo 11 flight was made too late to retarget TLI. The RTCC midcourse processor 
would be used to compute midcourse maneuvers during translunar coast in order to per- 
mit an LOI into the desired lunar orbit. The mismatch between the nominal translunar 
trajectory and the lunar-orbit orientation showed that, as originally specified, the free- 
return BAP options would yield nonoptimum answers in the region approximately 
20 earth radii from the moon. Two alternatives were available: (1) change of the 

weighting scheme to place more importance on the plane change at LOI (a form of symp- 
tomatic treatment) or (2) incorporation of the vector offset technique. The latter was 
selected and resulted in the program that was also used for the first manned lunar 
landing. 


Ensuring RTCC Reliability 

The most difficult and prolonged task of all was the effort to make the program 
completely reliable. For the real-time situation, a program was required that would 
not fail. The RTCC midcourse was required to optimize the smallest of maneuvers 
and still retain the capability to correct dispersions for which corrective maneuvers of 
several thousands of feet per second were needed. 

Because of the nature of iterative techniques that involved several independent 
variables, the Generalized Forward Iterator required an exhaustive study to determine 
the most reliable independent-variable step sizes and weighting schemes. Fine tuning 
of these parameters for a specific launch date or maneuver time could cause disastrous 
results in cases for which a different geometry was encountered. In addition to studies 
that were conducted to determine the proper step sizes and weighting schemes, critical 
trajectory routines such as Patch and LOPC that usually worked well were reconstructed 
to eliminate all known problems. At times, this reengineering entailed yet another 
weight and step- size study. 

In summary, the RTCC midcourse processor gradually evolved over a period of 
years as a result of constantly changing requirements. Key ideas and programing sup- 
port were contributed by personnel from various organizations. Many major develop- 
ments were actively pursued, only to be abandoned or to remain unused after being fully 
developed. Appreciation of the problem and of the behavior of the iterator resulted in 
specifications involving a sequence of steps that led to a final optimization computation 
instead of a single all-out optimization. The resultant program was more complex but 
afforded greater reliability. Perhaps the greatest progress was in human understand- 
ing of the problem and of the iterator used to solve it. 


LUNAR-ORBIT INSERTION 


Work on the real-time LOI Targeting Program proceeded in four phases. The 
first phase (pre-1967) involved learning about the available guidance equations and the 
inherent capabilities of the equations. The second phase (spring 1967) was the first 
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attempt at a targeting program. The problem of developing a real-time targeting pro- 
cedure was assumed to have been solved by an iterative technique in which the burn was 
simulated by integration through the guidance equations; therefore, it was assumed that 
the program had only to be built. This attempt was unsuccessful because the LOI prob- 
lem was more complex than was originally conceived. In the third phase (1967 to 1968), 
the problem, after closer examination, was better understood, and a design philosophy 
and program design were developed that should have been workable. An iterative tech- 
nique and integration through the guidance equations were used. However, before this 
program was built, the fourth phase was begun, in which operational simplifications 
were made to the LOI burn. The most important simplification permitted the LOI burn 
to be simulated by an impulse; therefore, the program actually used for the Apollo 
lunar missions was drastically changed. The philosophy that was developed in the third 
phase of the program remained the same, but the method of implementing the program 
was changed. 


Pre-1967 Development 

Interfa ce with guidance-equation development. - In 1964, MIT personnel developed 
a steering law (cross-product steering) for the spacecraft, which required values for a 
velocity -to- be- gained vector. For the various CSM maneuvers, several computer pro- 
grams were used to compute the values of this vector. A circularization guidance that 
was to be used for LOI was designed to provide a circular orbit at burnout, which oc- 
curred whenever the spacecraft position and velocity in the burn had an osculating ec- 
centricity of zero. Also, with this guidance law, the spacecraft would pass through a 
given inertial position. During the early work on the LOI targeting problem, the inten- 
tion was to gain knowledge of the capabilities of circularization guidance. This work 
was also necessary for the mission-planning trajectory scans; no effort was directed 
toward the specific study of the LOI targeting procedures. Because circularization 
guidance could result only in a circular orbit at burnout, no other profiles were studied. 

Objecti ves of initial studies. - The initial studies were completed through in-house 
efforts and tasks performed by prime contractors. The objectives of these studies were 
twofold. One objective was to determine which guidance variables controlled each tra- 
jectory parameter. Because no closed-form analytical simulation of the burn was found, 
an iterative approach was used to determine guidance variable values (e. g. , ignition 
time) to obtain specified orbits after the burn. The necessity of iterating was eliminated 
only when the LOI burn became so restricted by operational constraints that the burn 
could be simulated by an impulse. The second objective was to develop empirical equa- 
tions to compute various guidance variables and to develop polynomial simulations of 
the LOI burn. These developments were primarily for use in the mission- planning scan 
work to avoid the lengthy computer-run times associated with iteration through the guid- 
ance equations. 

Res ults and observations. - Several usable ideas were obtained from evaluation of 
the observations. A good understanding of circularization guidance and some under- 
standing of cross-product steering were acquired. Empirical equations for guidance 
variables and polynomial burn simulations were developed, and the major LOI trajectory 
problems that would have to be processed in the real-time targeting-update program 
were observed. However, no detailed knowledge existed concerning the LOI trajectory 
problems (e. g. , the effect of trajectory dispersions on the node of two orbits that are 
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nearly coplanar); only guidance capabilities were known. The iterative technique was 
solidified as the solution to the LOI targeting problem* just as it had been for the 
midcourse -correction problem. 

Several observations can be made about this early effort. Possible real-time 
targeting problems had appeared but were ignored. The LOI was not regarded as a 
serious problem because the RTE and midcourse problems were so complex compared 
with LOI that LOI was deemed relatively unimportant. Nevertheless* it was a mistake 
not to have had at least one person working full time on the LOI problem. A tendency 
developed to take the approach of "do it like the midcourse" or "the iteration can solve 
the problem" and to ignore the problems that had occurred. If this mistaken approach 
had continued* a workable LOI targeting program probably could not have been developed 
in the available time without a large effort being expended; however* the delay caused by 
the spacecraft fire in January 1967 provided additional time for work on the problem. 
Consequently* real-time capabilities and mission -planning freedom were not hampered. 

The probable reason for these mistakes was that the scope of the early work was 
too limited. The analysis of the guidance equations was necessary* but the development 
of the LOI targeting procedures should have been studied independently of the specific 
guidance problems. Profile changes* guidance changes* and trajectory problems should 
have been considered to gain an understanding of the real-time targeting problem so that 
the necessary engineering trade-offs could be made and a real-time targeting program 
developed. 


First LOI Targeting Program 

Cons iderations . - The development of the real-time LOI Targeting Program was 
begun in January 1967. A prototype set of RTCC computer programs for Apollo mission 
planning had been under development during 1964 and 1965. The prototype RTCC logic 
contained an LOI Targeting Program that was an iteration on ignition time and could not 
have handled dispersions* Little difficulty was expected in developing the program* be- 
cause it was assumed that only proper initialization of the iterator was needed; that is, 
the problem was assumed to be solved already. However* several events that influenced 
the program were occurring at this time* Some operational considerations were being 
advanced* mainly the problem of onboard burn monitoring, the solution of which later 
led to the elliptical lunar orbit after LOI and to the fixed- attitude LOI burn. 

Impact of initial operational considerations . - For the E-type mission, a simulated 
LOI burn into an elliptical orbit was performed. Because circularization guidance could 
not be used for this maneuver and because the guidances that could be used had been 
eliminated from the onboard computer to gain computer storage* a rendezvous guidance 
(Lambert's guidance) was evaluated for this maneuver. In this guidance, the velocity- 
to-be- gained vector was determined from Lambert's problem (given a time of flight and 
a target vector). It was decided to include additional guidance in the LOI Targeting Pro- 
gram to handle elliptical orbits after LOI, The development of the program logic would 
not be delayed for this guidance; however, the guidance logic would be added later if it 
could not be included in the initial program specifications. External AV guidance 
(eventually used for all CSM burns) was available but was not considered because of the 
concern that this guidance might be too sensitive to dispersions. 
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As tiie LOI Targeting Program developed, problems began to arise more fre- 
quently. The assumption that the problem was already solved inhibited complete exam- 
ination of the problem, determination of the real nature of the problem (in more specific 
terms than the generality, "target LOI"), and determination of the necessary engineer- 
ing trade-offs. As a result, this first targeting program was inferior. Many logic 
paths existed, each with an individual iterator setup. The run time was estimated to be 
long; and, because the simulations were available, an attempt was made to use the 
polynomial burn simulations developed in earlier work. This approach made the pro- 
gram highly inflexible, because the polynomials were tied to a specific profile and ve- 
hicle performance. Because of the problem with the program run time, consideration 
was given to expanding the polynomials so that they would have the capability to handle 
elliptical lunar orbits. 

Another aspect of the problem was that personnel working on the program were 
inexperienced in this type of work. A plan of attack and the directions the program de- 
velopment should take had not been established. However, this first attempt at a pro- 
gram resulted in valuable experience in real -time -program design. 

In the first attempt at the development of an LOI program, approaches to the 
problem were broadened. A better understanding of the iterator and of cross-product 
steering (independent of the velocity- to -be- gained vector computation) was deemed nec- 
essary. A critical realization was that situations occur when all the desired end condi- 
tions cannot be attained (i. e. , a physically insoluble problem) because the approach 
hyperbola is fixed. Therefore, one or more end conditions must be relaxed. However, 
the best maneuver that could be targeted would be as close as possible to the relaxed 
end conditions. It was also realized that, with the nature of cross-product steering and 
vehicle-performance capabilities, a maximum allowable AV for LOI would have to be 
specified as an external input to the program. These observations were the result of a 
closer view of the problem than had been taken in the earlier work. However, by early 
1967, a workable program was still a long way from completion. 


Second LO! Targeting Program 

Need for increased flexibility* - As the time for manned lunar flights approached* 
operational considerations were becoming more and more important. For this reason 
and because of the dissatisfaction with the first efforts at developing a program* a de- 
cision was made to take a fresh look at the LOI problem. 

Many perturbations occurred in the development of the LOI Targeting Program, 
which was originally designed to support a nominal 80- nautical- mile circular lunar 
parking orbit. The circularization logic was deleted from the onboard software. In 
addition* concern over degraded lunar module performance because of increased lunar 
module weight and the LOI monitoring problem resulted in reconsideration of elliptical 
lunar parking orbits rather than circular orbits* of lower altitude orbits, and of fixed - 
attitude steering rather than Lambert’s steering- Because of these uncertainties* a 
decision was made to redevelop this program to provide more flexibility. 

Design p hilosophy, - Reconsideration of the development of an LOI Targeting Pro- 
gram resulted in the development of a good design philosophy and the necessary techni- 
cal understanding to implement it* The design philosophy that was developed by late 
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1967 was carried over to the final program and primarily was responsible for the quick 
program development (approximately 1 month). This philosophy consisted of three 
parts* 


The first part of the design philosophy was carried over from the early program 
development efforts and Included the idea of relaxing end conditions* Initially, trade- 
offs had been made between obtaining the desired landing site and obtaining the desired 
orbit shape* In this second effort, the following priority was set: the desired orbit 
shape was to be obtained within the maximum allowable LOI AV constraints, and then 
the desired landing site was to be obtained if the orbit shape had been obtained* The 
reason was that the orbital geometry sometimes made passage over the landing site 
either impossible or obviously unreasonable, even with reasonably small dispersions in 
the lunar approach hyperbola, whereas only unreasonably large dispersions of the ap- 
proach hyperbola would prevent achievement of the orbit shape* During the first efforts, 
either the landing-site latitude or the miss distance at the landing site had been used as 
the iterator’s dependent variable to obtain a trajectory that would have been as close to 
the landing site as possible, within landing- site azimuth constraints. In the second ef- 
fort, because it was realized that what was desired was an orbit plane (or planes, if a 
range of azimuths at the landing site was acceptable) that passed over the landing site, 
the landing-site variables such as azimuth (or a range of azimuths), latitude, and longi- 
tude could therefore be replaced by a single variable, a wedge angle. Thus, it was nec- 
essary only that this wedge angle at the landing site be driven as near as possible to 
zero during the iterations, because the iterator could optimize in only one variable 
(i. e. , drive the variable as near as possible to a desired result)* Therefore, the con- 
cept of the wedge angle was one of the most critical realizations, for the landing site 
could now be attained by optimizing on only one variable (wedge angle). Optimization on 
the orbit shape was accomplished by fixing apolune altitude and optimizing perilune alti- 
tude {for elliptical orbits) or by optimizing circular altitude (for circular orbits)* 

The second part of the design philosophy involved the elimination of errors that 
resulted from making the lunar- orbit shape more important than the landing site. The 
solution was to provide the flight controller with more information than that required to 
evaluate only the planned maneuver- Therefore, the flight controller would have the 
capability to obtain a more acceptable maneuver or to make trade-offs. For example, 
the flight controller was provided with information about the intersection between the 
approach hyperbola and the two planes that passed over the landing site with the speci- 
fied two extreme azimuths. 

The third part of the design philosophy was to make the program general by spec- 
ifying as many degrees of freedom as possible to be left as inputs (e, g, , the apolune and 
perilune altitudes after LOI)* This philosophy allowed the flight controller to use avail- 
able information to compute other maneuvers if desired; this approach was also required 
because of uncertainties in the lunar -orbit profile and in the guidance. 

The second and third parts of the philosophy can be summarized by the statement 
that the program was designed to support automatically the known LOI options, but 
enough additional information was computed and displayed, and enough inputs were pro- 
vided, to handle the unexpected* It was hoped that the program would then be stable and 
relatively immune to perturbations or that at least the program would handle changes in 
the lunar-orbit profile procedurally until the program could be modified to handle these 
new profiles automatically. 


19 



Ml! 


Engineerin g trade-offs. - To develop the design philosophy, a complete under- 
standing of the trajectory and operational aspects of the problem was needed. With this 
understanding, the necessary engineering trade-offs could be made in order to imple- 
ment the philosophy. The following characteristics of the program were considered. 

1 . Iteration through the guidance equations could be used. 

2. The lunar-orbit plane and shape could be redefined by input. 

3. Lambert's targeting and external AV guidance could be used. 

4. Orbit shape could have priority over the landing site. 

5. No trade-off could be made between LOI AV and any in-orbit Ay. 

6. Often, the AV remaining could not be optimized. 

*7. No in-orbit maneuvers could be used to attain targeting objectives. 

In addition, polynomial burn simulations were to be used; however, because of the in- 
flexibility of the polynomials, it was decided later not to use them. 

Work was being completed to provide the necessary background for building the 
program. Lambert's guidance was thoroughly evaluated to determine which variables 
controlled each trajectory parameter and which variables should be used in the itera- 
tion. Because the end conditions were sometimes unattainable, an investigation of the 
optimization mode of the iterator was attempted. The important problem of lengthy 
computer run time was investigated by trying methods of further integration through the 
guidance (e. g. , larger step sizes). A computer program was to be built to allow eval- 
uation of some of the ideas. However, development of the program was slowed by the 
contractor personnel's lack of experience with the iterator and lack of understanding 
of the engineering, and by the lack of detailed direction and programing specifications 
by MSC. By the time this computer program was available, the final real-time program 
was already in use (with an impulsive burn simulation and no iterations); consequently, 
the contractor's work was never used. 

In summary, a workable computer program evolved as a result of the following 
four developments. 

1. The operational inputs were obtained. 

2. A good understanding of the problem was achieved. 

3. A new approach in thinking was taken. 

4. A design philosophy consistent with the first two developments was adopted. 

Most of the early work was not useful. Empirical equations, burn polynomials, 
and circularization- guidance knowledge eventually were discarded. However, the 
knowledge of cross-product steering and of LOI trajectory problems was useful. The 
second LOI Targeting Program was never advanced to the engineering stage; that is. 
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the computer program was never built so that the theory could be tested. Much time 
would have been required to develop a real-time computer program based on the theory. 
However, it was thought that a good basis had been established and that die second LOI 
Targeting Program had the capability to handle all LOI targeting changes that were 
likely to arise. This approach would not have been desirable if the problem were more 
constrained, but, because of the nature of the guidance, the approach was required. 


Final Program 

Operational inputs and simplifications. - At this point, a major operational input 
was obtained. To make the onboard attitude monitoring easier, a fixed-attitude maneu- 
ver was selected for LOI. The performance penalties of a fixed -attitude burn over a 
variable-attitude burn were negligible. Also, the decision was made to use an elliptical 
orbit after LOI to ease the overburn- monitoring problem. Because of these constraints, 
some major simplifications could be made. 

In one of the studies conducted during the second effort at developing a program, 
a very important discovery was that a fixed- attitude burn resulted in a postmaneuver 
orbit of which the altitude at the node between the pre maneuver and postmaneuver planes 
was equal to the pre maneuver orbit altitude at that point. Alteration of the burn AV or 
attitudes (or both} would not achieve a different result. This situation was unforeseen, 
and considerable time was spent in an effort to understand the problem. The discovery 
was important because, when a fixed- attitude burn was selected for monitoring reasons, 
it was no longer necessary to iterate through the guidance equations. Because the LOI 
burn could be simulated by an impulse, the lengthy computer run time and the possible 
unreliability associated with an iterative solution to the LOI targeting problem were 
eliminated. The only iteration necessary would be to determine the guidance param- 
eters needed to burn into the impulsively defined orbit, and this procedure would be no 
problem because of the work that had been done previously for many different hyperbolas 
and lunar-orbit geometries. 

It might have been possible that approaching the problem initially from a general 
viewpoint, that is, concentrating on guidance and trajectories in general rather than on 
a particular guidance (circularization), would have shown that a fixed-attitude burn re- 
sulted in no nodal altitude difference. If the desirability of the fixed-attitude burn had 
been revealed, it is probable that, early in the program, the fixed- attitude LOI burn 
could have been adopted and considerable work avoided. To justify the fixed-attitude 
burn, the operational simplifications would have had to have been reached at an earlier 
date. 


Use of the fixed-attitude burn eliminated the capability of targeting out planned 
nodal- altitude differences. However, because of the elliptical lunar orbit, this capabil- 
ity could still be achieved when the nodal altitude increased from the planned value as a 
result of dispersions, because the ellipse line of apsides could be rotated until the nodal 
altitudes matched. 

The second LOI program (which was based on use of the iterator) was not the best 
for particular constraints, but it would be acceptable for a wide range of constraints. 
Because of these new operational constraints, drastic changes were made in the LOI 
Targeting Program. The philosophy remained the same; the changes made were in the 
method of implementation. 
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Constructi on of the ta rgetin g program. - Relaxation of the end conditions was 
maintained because physically insoluble problems could occur. However, instead of 
computing only one solution (maneuver) that could attain the orbit shape within a given 
AV and then could obtain the landing site, 10 solutions were computed with various end 
conditions relaxed (perilune altitude, desired azimuth, wedge angle, etc. ). These 
10 solutions improved the program because several maneuvers were now available, and 
the flight controller could select the best maneuver, to the extent that the best could be 
determined by the mission conditions at that time. It was possible to compute the 
10 solutions because of the computational speed that resulted from the impulsive burn 
simulation. 

Relaxation of the requirement for passing directly over the landing site was still 
accomplished by the wedge-angle concept. Minimizing this wedge angle within a AV 
constraint was the means of coming as close as possible to the landing site. It was 
possible to compute the wedge angle at the landing site from the LOI impulsive point 
because solutions with a range of azimuths over the landing site have angular momen- 
tum vectors that very nearly lie in a single plane. After LOI, the angular momentum 
vectors of the planes that would pass over the landing site could be assumed to lie in the 
plane formed by the angular momentum vectors of the orbits (propagated back to LOI) 
associated with the two extreme azimuths over the landing site. With the use of this 
concept, the computation of the various LOI solutions was straightforward and simple. 

The 10 solutions fulfilled the requirements of the second part of the philosophy, 
providing the flight controller with information to make trade-offs and to use the inputs 
intelligently. Most of the degrees of freedom to the problem were specified as inputs. 

Tar getin g progra m us e. - The desire for a circular orbit at the time of the con- 
stant delta height (CDH) maneuver during rendezvous on the Apollo 11 and 12 missions 
illustrated how well this philosophy had worked. No automatically computed solution 
existed to establish a second maneuver to obtain a circular orbit at some future point 
after LOI, but a lunar- orbit perilune altitude could be determined that would allow 
LOI -2 to result in an orbit which would be perturbed so that it was circular at CDH. 
Determination of the lunar-orbit perilune altitude required knowledge of the nodal alti- 
tude and of the true anomaly on the hyperbola (which were computed by the program and 
displayed) and availability of the target perilune altitude as a program input. There- 
fore, in real time, the correct target perilune altitude would be determined from 
preflight- computed graphs after one run with the nominal perilune altitude. Thus, a 
new program requirement could be fulfilled by preflight work and real-time evaluation, 
without a change in the real-time program. 

Summar y and obser vations . - Program deficiencies did develop, however. Not 
all degrees of freedom were specified as inputs, and one particularly serious omission 
was the control of one of the two possible ways the line of apsides of the post- LOI 
ellipse could rotate. Some awkward procedures were used in the attempts to overcome 
this program deficiency. The omissions resulted in program changes. Some of the 
"do it like the midcourse" philosophy still existed, especially regarding the computa- 
tion of the AV remaining after TEI. Some difficulty resulted from the failure to view 
this portion of the program as more than a computation that had to be performed and 
then added to the display data after computing the impulsive solutions. Also, some of 
the procedures that were performed "like the midcourse" could have been accomplished 
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by a better method. For example, the lunar orbit was propagated by using conic tra- 
jectories with nodal regression, primarily because the same method was used for the 
midcourse program. 

After several missions, it was found that the problem had been over supplied with 
solutions for a range of approach azimuths to the landing site, because it became appar- 
ent that ground personnel were very reluctant to use an approach path other than the one 
for which the flight crew had trained and for which the lunar-orbit propagation had been 
verified. Although it was desirable, the computation of AV remaining after TEI was 
determined to be unnecessary. However, because of the situation at the time the pro- 
gram was designed (i. e, , that landing- site azimuth could easily change in real time), 
justification for excluding the range- of -azi muth capability would have been difficult. 
When the landing-site azimuth changed, the AV remaining after TEI could also change 
significantly; thus, justification for excluding the AV remaining after TEI would have 
been difficult also. 

The maneuver targets were computed by the Maneuver Planning Table (MPT), 
which iterated on guidance parameters to give a burn that attained the impulsively de- 
fined lunar orbit. Originally, the guidance parameters were to be computed in the LOI 
Targeting Program to eliminate the MPT interface. This type of computation was not 
used because the program could be put into the RTCC more quickly with the MPT inter- 
face. No problems arose as a result of this interface; therefore, the correct decision 
was not to compute the guidance parameters in the LOI Targeting Program. However, 
some inputs to the MPT were based on knowledge of the LOI geometry. To ensure that 
there would be no trouble in the computation of guidance parameters in the MPT, a set 
of controllable variables was defined in the iteration for guidance parameters. 

No inputs were available from the Lunar Orbiter Program. An attempt was made 
to determine the Lunar Orbiter procedures for LOI in the fall of 1967, but this study 
was unsuccessful. 

Although it was a mistake to delay the start of the program development for so 
long (until early 1967), the delay probably resulted in the development of a much better 
program. Had a program been working before the decision was made to use the fixed- 
attitude burn, it would have been difficult (although not impossible) to change the pro- 
gram. Consequently, the program-development delay probably resulted in a better 
real-time tool. 

Three major observations can be based on this experience. 

1. Operational inputs are important because operational simplifications may 
result in drastic changes to the targeting program. 

2. Program generality and flexibility are necessary because program require- 
ments and operational constraints can change. 

3. A thorough under standing of the problem is required for the development of a 
design philosophy consistent with the trajectory problems and the desired functions of 
the program and for an approach to the problem with an outlook that is not dependent 
upon previous methods for the solution of other related difficulties. 
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RETURN TO EARTH 


The RTE Abort Program was a real-time support processor through which maneu- 
vers could be computed to place a spacecraft on a trajectory that would return the space- 
craft to the earth. These maneuvers might have been determined for any state vector 
contained in cislunar space. Although the program name implied that abort or nonnomi- 
nal maneuvers were generated, the program also could compute the nominally planned 
TEI and TEMC maneuvers. 


Current Program Configuration 

The RTE Abort Program presented solutions on one of three real-time output dis- 
plays: an analog display (the TO Display) and two tabular displays called the Abort- Scan 
Table (AST) and the Return- to- Earth Digital (RTED) Display. The displays differed in 
(1) the amount of information given for each solution, (2) the number of solutions pre- 
sented, and (3) the precision of the solutions presented. 

Trade-Off Eh sp lay and solutions. - The TO Display provided solutions that were 
characterized by impulsive maneuvers, by conic (analytic) or patched conic coasts from 
maneuver to entry, and by a curve-fit entry simulation which would produce the landing 
point. This display presented a continuum of solutions for a range of maneuver and 
landing times on the premaneuver trajectory. Only the solutions that would return the 
spacecraft to a specified landing site were produced by the TO Display. Two types of 
landing sites were available. The primary target point (PTP) site was a specific latitude- 
longitude point on the surface of the earth. The alternate target point (ATP) site was a 
predominantly north -south line on the surface of the earth defined by as many as five 
latitude -longitude points. For both solution types, the TO Display presented the maneu- 
ver AV (for different landing times) plotted as a function of maneuver time. In addi- 
tion, miss distance to the PTP was given for the PTP mode, whereas latitude of landing 
was given for the ATP mode. Based upon the availability of solutions within the con- 
straints and maneuver times, the TO Display might contain a single solution or as many 
as 240 basic solutions. 

Abort- Scan Table Display and solutions. - The AST displayed up to seven discrete 
solutions that were characterized by impulsive maneuvers, by precision- integrated 
coast to entry, and by curve-fit entry simulation. For each solution, 17 parameters, 
including those on the TO Display, were tabulated. Eight solution modes were available 
in the AST. At a specified maneuver time, the AST could produce ATP and PTP solu- 
tions that corresponded to the solutions of the TO Display. A fuel- critical, unspecified- 
area (FCUA) mode at a discrete maneuver time was available. A time- critical, 
unspecified- area (TCUA) mode and a specialized FCUA mode called the extreme fuel- 
critical, unspecified-area (EFCUA) mode were available for earth reference. For 
moon reference, the three discrete modes (ATP, PTP, and FCUA) also had a search- 
mode counterpart. For the search modes, the solution was the maneuver within the 
constraints that required the lowest maneuver AV over a range of maneuver times. 

Return- to- Earth Digital Display and solutions. - The last display, the RTED, con- 
tained only two solutions. These solutions were the most precise in that they were to- 
tally integrated from the finite thrust maneuver to the guided atmospheric entry. More 


information describing each solution was also displayed; 55 parameters were listed. 

The RTED Display generated a solution either from one of the solutions currently stored 
in the AST Display or from a solution defined manually by the flight controller. The 
RTED Display solutions were available for transfer to other processors, and a space- 
craft target load could be generated for either solution. 

Characteristics of display usage. - Two general characteristics of the RTE Dis- 
plays, in the progression from the TO Display to the AST Display and then to the RTED 
Display, were that (1) fewer solutions were presented and (2) more precision for each 
solution became available at each ensuing display. Therefore, the TO Display had the 
greatest capability to compare or trade off solutions, and the RTED Display had the 
least capability. The TO Display provided the user with the capability to determine and 
compare the behavior of solutions over a wide range of maneuver times. Computation 
times were reasonable because the solutions were not integrated. However, the solu- 
tions were sufficiently accurate for selecting the possible candidates for the real-time 
situation. Then, the prime -candidate solutions selected by the flight controller were 
recomputed with more precision in the AST. From the candidate solutions, the one 
solution that was most appropriate was generated in the RTED Display and became 
available for incorporation into the planned trajectory. 


Early Program Development 

Apollo Trajectory Decision Logic Prot otype Program . - During 1964 and 1965, a 
prototype real-time-trajectory planning and evaluation program, known as the Apollo 
Trajectory Decision Logic Prototype (ATDLP) Program, was developed. Various mod- 
ules of the ATDLP Program comprised the abort- maneuver logic for a lunar -Landing- 
type mission. The definition of this abort-program logic occurred at a series of 
meetings between MSC and contractor personnel. The specification of this logic origi- 
nated at these meetings as well as from existing MSC and prime -contractor program 
logic and analysis. 

The ABORT P rogram . - Concurrently with the ATDLP Program, a program known 
as ABORT was being developed to serve as a real-time-program candidate and as a 
general abort- maneuver- analysis tool. The solution modes for the abort-processor 
part of the ATDLP Program generally paralleled those of the ABORT Program. The 
ABORT Program contained both earth- and moon- centered conic- solution logic as well 
as precision- integrated- coast logic and finite- burn- solution logic. The solution char- 
acteristics of each mode in the ABORT Program were determined from conic propaga- 
tions by scanning over the key trajectory parameters. Therefore, optimum solutions 
were conic optimums and not necessarily precision optimums. 

The MI NMAX Program . - A third program, called MINMAX, which had the capa- 
bility of solving abort problems and contributed logic to the ATDLP Program, was under 
development. The MINMAX Program solved trajectory-planning problems by an opti- 
mization scheme rather than by a scan approach. To obtain a solution, one set of vari- 
ables (independent variables) was adjusted so that a second set of variables (dependent 
variables) would acquire a desired set of values. The MINMAX Program also had the 
capability of generating precision- integrated coasting arcs as well as conic or patched 
conic arcs. For die MINMAX Program, the solution mode or characteristics were de- 
termined by the choice of dependent variables. A characteristic of this program was 
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that the attainment of a solution depended heavily upon good initial values for the inde- 
pendent variables and a proper set of weights for the choice of variables. 

Comparison of the ABORT and MIN MAX Programs as real-time candidates. - An 
evaluation of The ABORT and MINMAX Programs was initiated in the fall of 1965. The 
objective of the evaluation was to determine the capabilities and deficiencies of each 
program as candidate real-time abort- solution logic. The following types of solutions 
in both earth and moon reference were generated by the ABORT Program for the 
evaluation. 

1 . Time- and fuel-critical unspecified area 

2. Time- and fuel- critical specified site (PTP) 

3. Time- and fuel- critical water landing 

During the evaluation, logic was added to compute maneuvers that would return 
to an Inaccessible PTP with the smallest miss distance. Before this addition, only PTP 
solutions that always hit the target site with zero miss distance were generated. Also, 
all three solution modes were generated for some cases by using the precision logic of 
the ABORT Program as well as the MINMAX Program. 

From late 1965 to early 1966, the results and solutions that were obtained by this 
evaluation were being discussed by MSC and contractor personnel. Objectives were the 
understanding of the behavior of the solutions, the development of a method by which the 
solution behavior could be displayed, and the determination of which solution parameters 
should be presented to the flight controller. 


Initial Formulation of Abort Procedures 

Prelim inary operational program requirements. - In 1965, a second group of MSC 
and contractor personnel was assigned to formulate abort procedures and to design the 
supporting real-time displays. Early in 1966, the initial results were presented to MSC 
representatives concerned with flight control and flight dynamics. The abort procedures 
implied a highly automatic RTCC processor and would necessarily have been included in 
the logic of the program to acquire the desired automation. The resulting logic would 
produce different types of solution, depending upon the abort situation. At the same 
time, the RTE Program would contain a look-ahead feature in which the flight controller 
would anticipate abort situations by generating possible future solutions along the 
planned trajectory. Two types of abort displays were presented: (I) a graphical TO 

Display, called the Advanced Planning TO, which presented maneuver AV as a func- 
tion of total trip time and maneuver time, and (2) a tabular display, called the Abort 
Mode Selection Display, which presented a selected set of parameters for the various 
solutions that would be available for a particular maneuver time. 

Two general guidelines for the procedures group and the program-development 
group emerged early in 1966. First, the processor would not be highly automatic, al- 
though selection of the desired type of solution by the flight controller would be possible. 
Second, the abort procedures would not constrain the processor, but the real-time pro- 
gram would have a general solution capability. 
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Modifications of TO Disp lay r e quirements , - As the analysis by the program - 
development group continued,” the need for some type of TO Display became apparent. 
This graphical or analog display was better suited than a digital display to presentation 
of the key parameters for a large number of solutions. In addition to the maneuver AV 
and the landing time, the miss distance for the PTP solutions was observed to be a key 
parameter that was needed for solution comparison. Therefore, the original TO Display 
was modified so that maneuver AV, landing time, and miss distance would be presented 
for PTP mode solutions. 


Basic Program Definition 

Based on the suggestions of the procedures and flight control personnel, the 
program-development group defined the abort processor in 1966. The moon-centered 
logic of the ABORT Program would be used as the basis for the development of the 
moon- referenced conic logic. A new earth- centered conic abort logic was defined be- 
cause of the desire to produce PTP solutions that could miss the landing site. These 
programs would generate solutions by scanning the key solution parameters rather than 
by implementing any simple iteration schemes for each mode. This decision resulted 
from a desire to generate solutions that were nonoptimum in the sense that they would 
be between TCUA and FCUA solutions. The two conic programs would provide the ini- 
tial values of the maneuver (independent) variables for the MINMAX Program, and the 
selected parameters from the conic solution would provide the dependent variables. 

The MINMAX iterator was chosen because continued development of the iterator was 
assured by the availability of development personnel and because some success was at- 
tained by the iterator during the program evaluation. 

Additional capabilities were added to the conic programs as a result of program 
evaluation and procedural discussions. The search-on- maneuver- time option was added 
to the moon- referenced, specified- site options. The non-zero- miss-distance solution 
was implemented into the PTP mode for earth- and moon-referenced programs. The 
minimum- miss- distance PTP mode was developed in addition to the existing modes for 
the earth- referenced program. The ATP mode was added to earth- and moon- 
referenced programs; the water-landing mode was dropped. For the remainder of 1966 
and throughout 1967, the development of both programs continued. The accuracy of 
solutions was enhanced by the addition of AV calibration logic to both programs, and 
the reliability and computation speed of the programs were increased. 

The RTE Program logic was defined formally in the fall of 1966; the earth- 
centered conic logic was defined in October 1966; and the moon- centered conic logic 
was defined in February 1967. At this time, no programing requirements existed for 
any of the precision-trajectory computational logics or for the overall supervisory 
logic. Basically, the defined logic was the first-guess logic for the precision part of 
the program. This logic defined solution modes in three categories. 

1. In earth and moon reference: a TCUA and an FCUA, an ATP and PTP trade- 
off, a time- and fuel- critical PTP subject to a maximum miss distance, and a time- and 
fuel-critical ATP 

2. In earth reference: an EFCUA and a minimum-miss-distance PTP 

3. In moon reference: a search option for the ATP and PTP modes 
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Approximately 1 year after the initial definition of the program logic, several 
factors precipitated a redefinition of the logic. During the year, logic deficiencies 
were discovered and corrected, and some program limitations were removed. The 
program-development group continued to discuss the operation and application of the 
processor modes; the relative importance of the processor modes and the amount of 
redundancy among the modes were evaluated, Asa result, the moon- referenced TCUA, 
the earth- referenced minimum- miss- distance FTP, and the time -critical PTP modes 
were deleted from the processor in the second program definition. 

When the MINMAX logic was chosen as the basis for generating the precision 
solutions from the conic solution, no specific effort was initiated toward the selection 
of independent and dependent variables for the various conic- solution modes. General 
investigations were continued into the behavior of the abort solutions over a wide range 
of conditions and into the behavior of the various finite-burn guidance laws. In particu- 
lar, reliability and primary control parameters of the guidance laws were investigated. 
The Lambert cross-product-steering law required extensive investigation to determine 
a target vector placement scheme sufficiently general in scope to support a nonnominal 
abort maneuver. These investigations continued through the spring of 1968. 

Beginning in 1967, studies of the MINMAX- iterator variable setup began in ear- 
nest. The problem was to select those key parameters from the conic solution that, 
when used as dependent variables, would reproduce the desired characteristics of the 
conic solution with an acceptable AV penalty. Reliably generated solutions that con- 
verged quickly to the final solution values were needed. An initial definition of the 
precision- computation logic and the interfacing logic between the conic and precision 
logic were attempted in April 1967. The precision- computation logic to support the AST 
and RTED and the supervisory logic of the abort processor were defined in Decem- 
ber 1967 and February 1968, respectively. At this time, only two guidance laws, the 
external AV and Lambert's targeting in conjunction with cross-product steering, were 
defined for the RTED Display logic. 

During late 1967, emphasis was shifted from the PTP mode to the ATP mode be- 
cause of discussions among personnel, results from dispersion analysis, and shorter 
entry ranges being planned for lunar- return energies. The TEMC target objectives 
shifted from specified site to FCUA. The AST FCUA mode, although optimum in the 
conic mode, was not truly optimum in the precision mode and, thus, was not able to 
support TEMC targeting. The earth -referenced FCUA mode was altered to allow AV 
minimization in the precision (AST) mode by using the MINMAX iterator. Because 
schedules did not allow the development of any other precision FCUA mode, the in- 
creased optimality was acquired at the cost of a computer- run-time penalty and a lower 
convergence reliability. The moon -referenced FCUA was not altered in this manner 
because this optimization mode would not reliably yield convergence for moon- 
referenced cases. Two manual techniques were developed to increase the optimality of 
the moon- referenced FCUA mode. In moon reference, the ATP mode would yield a 
more accurate FCUA solution by iterating on the longitude of the FCUA solution to lower 
the maneuver AV. In addition, an investigation into the direction of the precision FCUA 
maneuver AV revealed that, for TEMC maneuvers, the AV was applied along the 
local horizontal relative to the earth. This maneuver attitude was also generally true 
for earth-referenced, corridor- control TEMC. To allow the applications of this knowl- 
edge in the RTCC, the manual -input option of the RTED was modified to allow the ma- 
neuver to be specified in an earth- referenced local- vertical /local- horizontal coordinate 
system. 
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The RTE Program in the Apollo 8 Mission 

The establishment of the testing and program delivery schedules for the Apollo 8 
mission in December 1968 caused the delay of checkout and the implementation of some 
options in the RTE Program. Neither the PTP mode nor Lambert's guidance would be 
verified for the Apollo 8 mission. Also, the moon- referenced search options would not 
be incorporated into the logic. The Apollo 8 RTE Program consisted of the three RTE 
displays and the following AST discrete solution modes: earth -centered TCUA, fuel- 
critical ATP, and FCUA. 


The RTE Program after the Apollo 8 Mission 

For the Apollo 10 mission in May 1969, the moon- referenced search options and 
the PTP mode were completed and verified. Lambert's guidance was never completed 
and, eventually, was eliminated from the program. Also, a new set of independent and 
dependent variables for the precision iterator setups was defined to improve speed, 
accuracy, and reliability. Between the Apollo 10 and 11 missions, no major change was 
made in the abort processor. 


Observations 

Three general observations seem to be apparent in retrospect. First, consider- 
able initial effort was expended on the moon- and earth-referenced conic logics to de- 
velop several modes. Ultimately, approximately one-third of these modes were 
discarded during final program development. Because the decision that the conic logic 
would supply initial values to the MINMAX iterator was made at the beginning of pro- 
gram development, the development seemed to be excessively dependent on this mode. 
Second, although the accuracy and optimization in the conic logic were always improved, 
the means of optimization in the precision logic was not considered. Only recently has 
the program expanded with the development of the gradient -check method for earth- 
referenced FCUA solutions and the application of the state vector offset technique that 
had been developed for the trans lunar midcourse processor. Third, because of the late 
start on the development of the precision computation logic for the RTE Program, time 
was available for the development of only the agreed-upon approach. 


ONBOARD SOFTWARE CONSIDERATIONS 


Onboard Midcourse Targeting 

The onboard midcourse routines were developed mainly at MIT, but the routines 
were given considerable evaluation at MSC. Schemes for TLMC and TEMC essentially 
attempted to place the spacecraft on a nominal trajectory. Virtually no interdevelop- 
ment existed between the onboard targeting techniques and the RTCC targeting tech- 
niques, although all personnel were aware of the developments within each area. 

In the mid- 1960' s, the two onboard midcourse targeting routines were among the 
first to be eliminated from the onboard computer because of increasing demands for 
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onboard computer storage and because of the decision that nearly all targeting for ma- 
neuvers during the lunar mission would be conducted from the ground control center. 
Therefore, an onboard TLMC program was unnecessary because the program would be 
used only if a malfunction of the ground equipment or a loss of communications oc- 
curred, in which case it was assumed that an abort maneuver would be required or a 
midcourse maneuver would be delayed until such time as the ground facility had the 
capability to solve the problem. Essentially the same reasoning applied to the TEMC 
targeting routine, except that a targeting program would be needed if communications 
were lost. Such a program already existed in the form of the onboard RTE Program. 
Therefore, the TEMC Targeting Program was eliminated from consideration for the 
spacecraft computer. 


Onboard Return-to-Earth Targeting 

The onboard RTE Program was developed mainly at MIT. At the outset of the 
Apollo Program, MIT and MSC personnel agreed on the program requirements and 
began development. The same MSC personnel were also responsible for the develop- 
ment of the RTCC RTE Program, so that some interdevelopment between the onboard 
and ground targeting schemes existed. Eventually, personnel at MSC were forced to 
devote practically all of their efforts to the development of the RTCC RTE Program. 

The MSC personnel, however, continued to monitor development of the onboard program 
and maintained an in-house simulation corresponding to the MIT version of the program. 
An extensive effort was, made by MSC personnel to verify the onboard program. As a 
part of this verification, the onboard results were compared with RTCC results for 
similar cases. When the two programs had similar constraints and the same inputs, 
the results of the two programs agreed. The RTCC RTE Program necessarily had the 
capability of providing a greater variety in types of solution. The onboard system had 
a fuel -critical and a time- critical mode. Inputs could be varied in the time- critical 
mode to change landing longitude. 

The onboard RTE Program was also affected by the increased demands upon on- 
board computer storage space. Originally, moon- and earth- reference logic had been 
in the program. Because the Mission Control Center could supply block- data-type 
solutions to the spacecraft before the vehicle entered the lunar sphere, the moon- 
centered part of the program was one of the first items deleted from the computer. 

The only serious deficiency in the program was uncovered during verification of 
the onboard RTE Program for the Apollo 8 mission. An implicit constraint on the entry 
speed existed in the program. This limit was originally thought to be the parabolic 
speed at the altitude of entry interface; however, shortly before launch, the verification 
effort showed that the limit was considerably lower than the parabolic value. This low 
limit meant that, for several cases, many of which were nominal return trajectories 
from the moon, the onboard system would call for a maneuver merely to increase the 
RTE time, even when the spacecraft was on a satisfactory trajectory. A workaround 
procedure was developed by personnel of MSC, MIT, a contractor, and the flight crew. 

A crew checklist was devised for the procedure, and the procedure was verified a few 
days before lift-off. This limit in entry speed was corrected to a sufficiently large 
value for the Apollo 10 onboard computer program. The verification efforts at MSC 
have shown no serious errors in the program since that time. 
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CONCLUDING REMARKS 


The development of targeting techniques for the translunar injection, translunar 
midcourse, lunar-orbit insertion, and return- to- earth maneuvers in the Apollo lunar 
missions has been documented. The result of the targeting-technique development was 
a set of computer programs that is used in the real-time computer complex to calculate 
the guidance parameters for each maneuver. All of these programs, except the 
translunar-injection targeting-update processor, have been used successfully to target 
maneuvers on each Apollo mission thus far. 

The development of each of the targeting programs was heavily dependent upon 
other developments that took place concurrently in the Apollo Program (e. g. , guidance- 
equation development, mission-profile evolution, flight-hardware specifications, etc. ). 
Consequently, the requirements for the targeting program changed as guidance equa- 
tions were changed, as the mission profile changed, and so forth. In one instance, this 
proved to be beneficial: the existing lunar-orbit-insertion targeting processor has 
evolved from the final definitions of the mission profile (the two -burn lunar- orbit inser- 
tion) and of the onboard guidance equations (which call for constant- attitude maneuvers). 

The other three targeting programs depended heavily upon the Generalized For- 
ward Iterator, and, as the name implies, generalized iterative techniques were used 
extensively. Nevertheless, differences existed among the three programs. Develop- 
ment of the Return- to- Earth Targeting Program was based on the intention to use, 
first, several conic programs and, finally, the iterator to search for the final solution. 
The translunar midcourse processor used several steps to arrive at a solution, and 
each step contained some iteration. The same process existed for the translunar- 
injection targeting-update processor. 

Considerable knowledge has been gained in the development of these targeting 
techniques and computer programs. Each system has been constantly refined, and new 
analytical methods are still being evolved. 
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f The aeronautical and space activities of the United States shall be 
conducted so as to contribute ... to the expansion of human knowl- 
edge of phenomena in the atmosphere and space. The Administration 
shall provide for the widest practicable and appropriate dissemination 
of Information concerning its activities and the results thereof ?* 

-—National Aeronautics and Space Act of 1958 


NASA SCIENTIFIC AND TECHNICAL PUBLICATIONS 


TECHNICAL REPORT'S: Scientific and 
technical information considered important, 
complete, and a lasting contribution to existing 
knowledge. 

TECHNICAL NOTES: Information less broad 
in scope but nevertheless of importance as a 
contribution to existing knowledge. 

TECHNICAL MEMORANDUMS. 
Information receiving limited distribution * 
because of preliminary data, security' classifica- 
tion, or other reasons. 

CONTRACTOR REPORTS: Scientific and 
technical information generated under a NASA 
contract or grant and considered an important 
contribution to existing knowledge. 


TECHNICAL TRANSLATIONS: Information 
published in a foreign language considered 
to merit NASA distribution in English. 

SPECIAL PUBLICATIONS: Information 
derived from or of value to NASA activities. 
Publications include conference proceedings, 
monographs, data compilations, handbooks, 
sourcebooks, and special bibliographies. 

TECHNOLOGY UTILIZATION 
PUBLICATIONS: Information on technology 
used by NASA that may be of particular 
interest in commercia l and other non -aerospace 
applications. Publications include Tech Briefs, 
Technology Utilization Reports and 
Technology Surveys. 


Details on the avail ability of these publications may be obtained from: 

SCIENTIFIC AND TECHNICAL INFORMATION OFFICE 

NATIONAL AERONAUTICS AND SPACE ADMINISTRATION 

Washinfton, D.C 20546 



